Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000115_owner-urn-ietf _Fri Oct 25 14:28:12 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA00247 for urn-ietf-out; Fri, 25 Oct 1996 14:28:12 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA00242 for <[e-mail]>; Fri, 25 Oct 1996 14:28:10 -0400
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA07369  (mail destined for [e-mail]); Fri, 25 Oct 96 14:28:05 -0400
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
          id <[e-mail]>; Fri, 25 Oct 1996 20:27:12 +0100
Subject: Re: [URN] Unicode for NSS query
To: [e-mail] (Larry Masinter)
Date: Fri, 25 Oct 1996 20:27:11 +0100 (MET)
Cc: [e-mail]
In-Reply-To: <96Oct24.182227pdt."2763"@golden.parc.xerox.com> from "Larry Masinter" at Oct 24, 96 06:22:27 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2336
From: Martin J Duerst <[e-mail]>
Message-Id: <"josef.ifi..655:25.09.96.19.27.19"@ifi.unizh.ch>
Sender: [e-mail]
Precedence: bulk
Reply-To: Martin J Duerst <[e-mail]>
Errors-To: [e-mail]

Larry Masenter wrote:

>The way that i think of this is that the constraints:
>
>1 'has a unique sequence of octets that can be unambiguously interpreted by a
>  system'
>
>2 'has a unique sequence of glyphs that can be unambiguously displayed
>  and subsequently entered by a user'
>
>cannot be mutually satisfied. The simplest way to think about this is
>to have two kinds of representations of URNs: as a canonical sequence
>of octets, and as a user-entered string. Every URN has a single
>canonical representation, and the user entry method must map it to the
>canonical representation. No embedded URN-as-protocol-element should
>require canonicalization. The protocol for 'canonicalizing' a name may
>not be the same as the protocol for 'resolving' a name or asking for
>information about it.

Larry, I have some difficulties understanding you. By user-entered
string, do you mean the stuff on the cardboard box, and maybe the
pixels on the screen that the user sees when typing it in? Or do
you mean some kind of represenation that is moved around inside
the computer?

And why do you think that the two cannot be mutually satisfied?
It works for ASCII, anyway. For some other scripts, it is a little
bit more difficult, but some of these problems are similar to
what we have currently when somebody confuses "O" and "0" or
"l" and "1" and "I", and others, such as the A-grave case,
could be defined by normalization, which would also be required
for deriving your "canonical representation".

The problem of embedding is of course a tough one. One way to
interpret your statement is that it means that e.g. in an HTML
document, URL/Ns would only appear in the %HH notation (because
arbitrary octets would not usually pass the SGML parser).
This would indeed be rather restricting. I could easily immagine
that a Japanese document author constructs a document encoded
in SJIS, and just writes down a Japanese URL/N from the cardbord
box as is. It would technically be no problem for the browser
to take this URL/N, interpret it as SJIS, convert it to UTF-8,
maybe normalize it, and then pass it to some resolving mechanism.

If you see some problems with this, please tell me. If you don't
want to call the visible (e.g. in SJIS) form an URL/N, I can
accept that, but users will soon call it that way anyway.

Regards,    Martin.